Example Call Flows

This section contains call flows that follow show how a SwitchKit call processing application (CP App) communicates with the SwitchKit TEP.

Incoming Call

The CP App parses the RFS with Data and passes the parameters (Call ID and Called Number) in the 0x0100 IAM message. The TEP responds with an IAM message that indicates whether the call request was successful.

u IAM – Tag2 = 0x0200 - successful

u IAM – Tag2 = 0x1100 - unsuccessful

If the inbound call request is successful (0x0200 received), then the CP App should send a Generate Call Processing Event of Answer to the switch. Once the Ack for this is received, the CP App sends a 0x1000 IAM to the TEP informing it that the call is now answered.

If the inbound call request is unsuccessful (0x1100 received), then this IAM will include a TLV (0x6D72) that indicates the reason the call was refused by the TEP. Upon reception of this IAM, the CP App should either try the request again, or release the call

.

DTMF Detection

The TEP is responsible for turning the Digit Detection on and off. Digits will be sent to both the call processing application and TEP.

Play Audio

The CP App knows when the TEP is playing announcements to the channel.

Record Audio

The CP App knows when the TEP is recording audio from the channel.

Far-Side Hangup – Single Inbound Leg

The TEP receives the Channel Released message but does not perform action based on this. It waits for the IAM – Tag2 = 0x0800 message, which causes the TEP to perform clean up operations for the channel.

Near-Side Hangup – Single Inbound Leg

This is a request from the TEP to the call processing application to release the channel.

Blind Transfer – Hairpin – Success

For all the transfer scenarios, the IAM - Tag2 = 0x0300 message will contain a TLV 0x6D6C that indicates the transfer type (blind or bridge). From TEP perspective, all the Blind Transfer scenarios are handled the same. The IAM - Tag2 = 0x0802 will cause the TEP to stop monitoring the channel and clean it up.

Note: The two parties are talking between the time of the Call Processing Event of Answer, and the switch generated park that is performed because of a distant end release.

Blind Transfer – Hairpin – Failure

The IAM – Tag2 = 0x0802 will cause the TEP to stop monitoring the channel and clean it up.

Blind Transfer – Two B Channel Transfer (TBCT) – Success

The IAM - Tag2 = 0x0802 will cause the TEP to stop monitoring the channel and clean it up. The PPL Event Indication of ISDN Notify is sent from the proceeding switch when the call is no longer active (parties have hung up). This indication provides a means (to the CP App) for determining the call duration after the call has been handed back to the proceeding switch.

Blind Transfer – Two B Channel Transfer (TBCT) – Failure

The following call flow shows what would happen if the previous switch rejects the TBCT.

Note: If the outseize to a B-Leg fails, the call flow will be the same as Blind Transfer – Hair Pin – Failed.

Bridge Transfer – Success

An IAM - Tag2 = 0x0400 message is sent back to the TEP once the outbound leg has been determined and successfully outseized.

An IAM - Tag2 = 0x0401 will then be sent reporting the Call Processing Event of Answer. If the transferaudio attribute of the transfer element is not null, the TEP will be required to issue a Play File Stop upon reception of the IAM - Tag2 = 0x0401 message. In this scenario, the CP App connects the inbound and outbound legs once the Play File Stop has been echoed to the CP App.

If the transferaudio attribute is null or not present, the CP App can connect the inbound and outbound legs upon reception of the Call Processing Event of Answer, and the TEP would not issue a Play File Stop.

Bridge Transfer – No Answer

When the CP App receives the successful RequestChannelAck, it starts a timer with duration equal to the connect timeout attribute of the transfer element. No timer is started if this attribute is not present or is null. Upon expiry of this timer, the call processing application will send a IAM - Tag2 = 0x0403 (with the reason TLV set to No Answer).

Bridge Transfer – Failed

The IAM - Tag2 = 0x0404 message is sent to the TEP for any of the following reasons:

u Bad Number

u Caller Release

u No Answer

u No Channel

u User Busy

The 0x6D70 TLV in this IAM indicates which of these is the reason for failure.

Bridge Transfer – Caller Disconnects before Connection

The IAM - Tag2 = 0x0403 is generated by the CP App if it receives a Channel Release message for the A-Leg while attempting a transfer for this channel.

The IAM will indicate the failure reason (TLV 0x6D70) as "Caller Release." The TEP and CP App will then perform the needed clean up

.

Bridge Transfer – Caller Disconnects after Connection

The CP App acts on the Channel Released message by sending an IAM - Tag2 = 0x0800 message to the TEP. This causes the TEP to clean up this channel.

At the same time, the CP App will be driving the B-Leg to an idle state, and sending an IAM - Tag2 = 0x0901 upon completion.

Bridge Transfer – Called Party Disconnects after Connection

The CP App acts on the Channel Released message by sending an IAM - Tag2 = 0x0900 message to the TEP for the B-leg. This causes the TEP to clean up this channel.

Bridge Transfer – Caller Aborts (Releases) Transfer

In this scenario, the caller decides to stop the transfer attempt. The actions taken by the CP App upon reception of IAM - Tag2 = 0x0500 depend on the state of the transfer.

The CP App will send back an of IAM - Tag2 = 0x0600 once the call is aborted.

Bridge Transfer – Called Party Disconnected due to MaxTime Expiry

CP App starts a timer when it receives an answer indication on the B-Leg. The timer duration is equal to 0x6D6E TLV it received in the IAM - Tag2 = 0x0300 message.

If the TLV is not present, the timer is not started. The call flow below shows the events that occur upon expiry of this timer.